I like the fundamental mechanism, but find it a bit complex of how it could be used. Specifically JdbcTestHelper suggests that a whole helper class is needed which could perhaps be done by better utilities in the main classes.

The JdbcTestHelper is just a helper for the test classes to make it easier to set up a database, and do some extra queries for test purposes.

To use the new feature in embedded mode, you would simply just create an instance of your extended JDBCSessionDataStore class and set that on your context:

   DefaultSessionCache sessionCache = new DefaultSessionCache(sessionManager);
  sessionCache.setSessionDataStore(new MyJDBCSessionDataStore());

If you want to use a SessionDataStoreFactory to automatically create instances of your extended JDBCSessionDataStore as necessary for each new context, you just have to extend the JDBCSessionDataStoreFactory and override the getSessionDataStore() method to return a new instance of your class rather than the standard JDBCSessionDataStore.

If you want to do this via a module, then of course you need to write a .mod file.

The fact that all SessionDataStores do not use this mechanism, suggest that perhaps another subclass of AbstractSessionDataStore is needed. Perhaps a SerializedSessionDataStore to indicate that serialization is used.
Maybe, I'll explore.

It then feels like we could definitely offer a SerializedSessionDataStore.Compressed subclass that wraps any other SerializedSessionDataStore and does the stream wrapping for compression.
Perhaps we could offer the gzip style of compression as an option, however I'm sure there are many more types of compression that users may be interested in.

If the replaceObject method was delegated to a protected method on SerializedSessionDataStore, then it too could be intercepted with a wrapper provided by us.
Maybe, I'll explore.